テスト駆動開発 | Kent Beck, 和田 卓人
https://m.media-amazon.com/images/I/719E-POor7L.jpg https://amzn.to/3lrIZm0
kubokawa.icon 理解や実践より先にまず目を通すことを優先した．2時間くらいかけて第一部を通読した．他の部分も適宜読み進める．また，これは写経を必要とする書籍だと思う．リポジトリつくって，やっていく．
どんなもの？
「テスト駆動開発」という開発技法について日本語訳したもの．ライオンが腕を組み疑問を呈するあのAAで有名．
記述言語がJAVAなのでとっつきにくく感じてしまうが，「テスト駆動開発 写経 〇〇（言語名）」でググると大概の場合Forerunnerがせっせとテストを書いてくれている（ので自分も写経するべし）．
先行事例と比べてどこがすごい？
テストという概念にきちんと触れたのはこれが初めて（恥ずかしながら）なので，先行例と比べることが出来ない．でも，プロセスはなんとなくこれまで自分がプログラミングに触れてきた中で確かに良いと思えるような流れであったので，きちんと明文化されて嬉しいという漠然とした感覚がある．
1. まずはテストを一つ書く
2. すべてのテストを走らせ、新しいテストの失敗を確認する
3. 小さな変更を行う
4. すべてのテストを走らせ、すべて成功することを確認する
5. リファクタリングを行って重複を除去する
技術や手法のキモはどこ？
エディタ上でコードとにらめっこするだけだと頭のメモリが不足するという問題が発生する．これをTODOリストを作るという策で解決する．
「失敗する」ということへの心理的負荷をゼロにする．失敗してはいけないという思い込みからの脱却．
細かなステップを踏む．少しずつ確実に完成へ近づく．
kubokawa.icon 世の中にはたくさんのTODOリスト作成サービスがあるが，リポジトリと直接結びついているという点で Github project を採用した．「これからやること」「今やっていること」「やり終えたこと」，およびこれらがどの程度の重要性を持つのか？といったラベリングがGUIで簡単にできる．こうすると，単にコメントでコードにTODOを埋め込むよりは快適になる． kubokawa.icon 特に，TODOのトリアージという概念に出会ったのは思いがけない幸運だった．これにより頭の中のデフラグが自前で簡単にできるようになり，生活空間の雑念がクリアになった．
議論はある？
そもそもの「テストの書き方」「アルゴリズムのひらめき」などは自身のプログラミング能力に起因する．
テストが書けたからと言ってプログラミングが爆速で進むわけではない．寧ろコード記述量が爆発して遅々たる歩みになるかもしれない．
というか快適なテスト環境を整えるのがまず難しいかも？kubokawa.icon
次に読むべき書籍は？
code:t_wada
,、,,,、,,,
_,,;' '" '' ;;,,
（rヽ,;''""''゛゛;,ﾉｒ）
,; i ___ 、___iヽ゛;, テスト書いてないとかお前それ@t_wadaの前でも同じ事言えんの？
,;'''|ヽ・〉〈・ノ |ﾞ ';,
,;''"| ▼ |ﾞ゛';,
,;'' ヽ ＿人＿ / ,;'_
／ｼ、 ヽ ⌒⌒ / ﾘ ＼
| "ｒ,,｀"'''ﾞ´ ,,ﾐ|
| ﾘ、 ,ﾘ |
| i ゛ｒ、ﾉ,,ｒ" i _ |
| ｀ー――-----------┴ ⌒´ ）
（ヽ _____________ ,, ＿´）
（_⌒_______________ ,, ィ
T |
| |